> I've written a raytracer using vectors that use operator overloading. It
> was much easier to see what the code did than it is in POV, which uses
> macros for the vector operations.

Well yes, I'm not debating that. I'm saying for what you're doing it's better to
deal with things on a cleaner more mathematical basis, but for what I do at work
it's better to deal with things on a more technical implementation-based level.

> > > And this
> > > still isn't an argument against the existance of operator overoading.
> >
> > I never said it was!!!
>
> Yes you did...in a reply to one of my earlier messages:

No, I said it was an argument against the *use* of operator overloading, not
it's existence. I'm not saying it should never be used, I'm just explaining why
we don't use it.

> If you don't know anything about optimization. You optimize the big
> things first, algorithms and specific bottlenecks. You do the smaller,
> more work for the return items later, if necessary.

Which still is not a reason to hide what the code is actually doing.

Besides, a good optimiser does neither of those, you begin by profiling the
system extensively to ascertain what is slow. It doesn't matter how cumbersome
the big concepts are, or how badly implemented the low level things are, all
that matters is how long things take.

> By forcing more
> focus on every little operation done, you make it more likely that some
> larger problem will go unnoticed,

This is a valid point, but you must see that this is a balance. Depending on
your needs you choose how high/low level you want to be. If you only care about
the simplest processes you work in assembler, if you care most about the overall
structure you code in OO. We have gravitated to a point a little above the
functionality supported by C, and a little below true OO C++. This is the
balance that works for us, but I do not suggest it is applicable to all
situations.

> And abstracting things can be of
> great help in creating a tight, efficient module that is still both easy
> to use and understand.

High level code can be very good for dealing with high-level concepts. And
certainly as the games become more sophisticated people move naturally to higher
level concepts. But at this point in time the people I have worked with feel
that we're still dealing with concepts best expressed by C-style code with just
a few C++ features.

> And I don't buy your argument about vector-matrix
> multiplication...if you're doing high-performance code, you should
> always be aware of the types you're working with.


But how do I gain this awareness if it's not my code? Last project I was on had
20 programmers, and I was one of the main people assigned to optimise things. It
was more important to me to see how the code worked at a lower level than to see
nice clean algorithms.

However I know there are other games companies that go all out for OO code,
because they wish to code at a higher level. They do not produce such efficient
code as we do :)

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message